ERP - мнение о результатах внедрения, позитивно или негативно Часть 3
========================================================================
КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4347 от 2007-02-13 участников 1915 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Уважаемые коллеги,
в процессе нашего обсуждения мы забыли про одно весьма важную вещь. Если услуги внедрения поставляются компанией-внедренцем, то эта компания, как правило, уделяет большое внимание подбору квалифицированных консультантов и менеджера проекта, планированию проекта и созданию проектной группы со стороны заказчика. Но этими мероприятиями внедренец, по бОльшей части, страхует собственные риски и лишь косвенно влияет на качество проекта.
Главного элемента, которого не хватает в подавляющем количестве проектов - это отсутствие архитектора системы. Причем, архитектора должно быть два! Один архитектор системы управления бизнесом со стороны заказчика, а второй - архитектор внедряемой системы со стороны поставщика. В идеале, если архитектор внедряемой системы со стороны поставщика не только знает внедряемую систему досконально, но и сам является опытным бизнес-консультатом, хорошо разбирающемся во всех типовых бизнес-процессах, а еще лучше, и в отраслевой специфике заказчика. Архитектор системы управления бизнесом со стороны заказчика должен также обладать хорошей компетенцией в области всех бизнес-процессов компании, а также должен иметь высокую квалификацию в области финансов. Последнее обусловлено тем, что, как ни крути, но стержнем всех систем управления предприятием является финансовый контур. В одних системах, как например, в Аксапте, Навижн, 1С, - это видно невооруженным глазом, в других - это менее заметно. Такая ситуация сложилась исторически, т.к. до недавнего времени на Западе, а у нас и сейчас, подавляющее количество управленческих решений принимается на основании финансовых показателей, как плановых, так и фактических.
Поиск таких архитекторов в для компании внедренца - задача нетривиальная, к тому же, это весьма недешевые специалисты. Для заказчика наличие такого специалиста вообще случай из "области фантастического везения", а у многих даже нет понимания, что такой специалист необходим. Вот и делаются проекты "как-нибудь" со всеми прелестями неквалифицированного "допиливания" систем в ходе и после внедрения, и потери былой легкости управления бизнесом после окончания проекта.
Об этих проблемах я знаю не по наслышке, т.к. сам участвовал в подобных проектах, как и со стороны заказчика, так и со стороны внедренца. Ну где вы видели дом, который строит один прораб не имеющий архитектурного плана и архитектурного надзора? А при внедрении систем управления, почему-то, считается, что если ты хороший менеджер проекта (читай "прораб"), то и с архитектурой системы (читай "решения") справишься легко.
-- Алексей Сидоров.
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4350 от 2007-02-13 участников 1923 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Доброго дня ,
Продолжаем разговор :))))))
>>> какой может быть вопрос если человек 2 месяца назад занес сумму >>> оплаты материалов по договру и с тех пор эта сумма не изменялась?
MC> А вы уверены что она в системе не изменялась?
>>> даже когда мы начинае разбирать отчет по составляющим, т.н. идем на >>> прямую к цифрам, они как были так месяц назад так и остались :)
MC> Вопрос неоднозначный, я бы начал с проверки того, по какой формуле эта MC> сумма считается... И откуда берутся данные для расчета этой самой MC> формулы.. Данные берутся из проведнных в учет документов, все доки живут на счеах по направлениям. например материалы. там отражено все списание материалов в разрезе договоров, номенклатуры и т.п. Вы можете возразить что какойдо деверсан взял и сменил скажем направление списаним, т.е. номер договора, а вот и нет, если отсотировать все списание по договрам то цифра не бьется с отчетной :))))
MC>>>>>> Документы были подписаны? MC>>>>>> В том числе и как и дополнительные соглашения к договору? >>> давайте пропишем как еще нужно ходить в туалет чтоб программа >>> работала хорошо :) >>> подпсам договр и акт (акт с перечнем недоработок) да наша вина в >>> том что мы не додавили внедренцев на их устранение, тут наш косяк, >>> но я думаю если вы платите деньги то люди должны делать самим а не >>> после твоих просьб
MC> В целом, согласен что не все может быть описано, но если что-то MC> написано, то внедренцы имею право эти требования понимать буквально.. а отмазки типа у вас сетевые провода криво положены потому отчет неработает, как вам? конечно утрированно, НО. были постоянные зацепы на нецензионное ПО неграмотно построенную локальную сеть, вирусы и т.д и т.п. вплодь до того что компьютер не той конфигурации, ну и что что он отвечает требованиям программы заявленным в инструкции
>> Именно об этом и я пытался сказать, но как видите - есть мнение, что >> клиента надо доить, раз он дурачок - вот нас и доят - это же бизнес! >> Боюсь только что такой бизнес умрет, не родившись толком.
MC> Ну наличие большого количества Элексиров на рынке говорит об MC> обратном... ;) У нас не только рынок ПО так построен
>>>>> Документы были подписаны, было составлено ТЗ (составляли >>>>> внедренцы, за что получили копеечку) с нами согласованное. >>>>> половина отчетов не сделана, от блока складской учет пришлось >>>>> отказаться, т.к. если по складу такие заморочки пойдут (с >>>>> остатками материалов постоянно меняющимися) можно контору >>>>> закрывать сразу >>> MC>>>> Тоже странное утверждение, если в договоре или ТЗ написано, что MC>>>> должен формироваться такой-то отчет по таким-то данным и его нет MC>>>> в системе - то можно говорить о неисполнении условий договора.. >>> была уменьшина сумма по договру. Еще раз повторюсь, то что сайчас
>>> чтото работает это далось очень большой ценой >> Не всегда заранее можно прописать о том какой нужен отчет, потому >> что сначала
MC> То есть сейчас вы не знает какие отчеты вы готовите и какие данные для MC> принятия управленческих решений вам нужны?
>> многие моменты кажутся простыми и логичными, но потом вступают в >> противоречие с логикой системы и не могут быть созданы. Пример: Мы >> просили обеспечить историчность системы - чтобы можно было видеть в >> какой момент кто внес информацию в систему, чтобы состояние >> планирования можно было посмотреть в любой момент времени в прошлом.
MC> По моему это чуть ли не единственное достоинство системы - знать кто MC> какие и когда данные ввел, ИМХО требование обязательное
>> Разработчики сказали - сделаем! Второе пожелание было обеспечить >> возможность внесения изменений задним числом в управленческую >> информацию.
MC> А это зачем? Если такое делать то: MC> 1. достоверность информации теряется; MC> 2. сложность разработки систему увеличивается пропорционально MC> количеству данных и пропорционально квадрату таких пожеланий; MC> 3. скорее всего такие изменения не затронут все отчеты - вы будите MC> либо по разным отчетам получать разные данные либо "править отчеты MC> ручками" как в случае, который рассказал Федор. MC> 4. Смысл внедрения теряется, если человек сможет "непонравившиеся" MC> цифры исправлять руками. Если он видит ошибку в отчете, то пусть ее MC> исправляет не в отчете а в первичных данных.. - тогда уж точно лучше MC> пользуйтесь Екселем..
>> Разработчики сказали - без проблем! Никто не подумал что эти >> принципы противоречат друг другу. Это наверное не вина разработчика >> или клиента - такие моменты проявляются позже. Просто на их расшивку >> уходить огромная масса времени и сил. >> MC> Вообще говоря они не противоречат друг другу, можно сделать систему, MC> которая каждое нажатие клавиши журналировала, в том числе и MC> корректировки в системе но это больше нужно для прокурора, чем для MC> получения истиной информации..
MC>>>> Смысл в том, что любая программа, любой файл это MC>>>> последовательность "1" и "0", если есть двоичный редактор, то MC>>>> за некоторое ограниченное, но очень большое время можно создать MC>>>> любой такой файл, в том числе и любую программу, имеющую вид MC>>>> файла... >>> я знаю что такое асемблер (по первому диплому я програмист) от меня >>> ускользает смысл того, что если человек знает как работает его >>> программа то почему он этого не расказывает.
MC> Во-первых не факт что знает, а во-вторых зачем делиться знаниями - MC> теряется незаменимость людей.. тогда его позиция очень правильная
MC>>>>>> Это обещание документально закреплено? если так, то почему вы MC>>>>>> заплатили деньги за внедрение, и не потребовали, например, MC>>>>>> через суд выполнить обещания? >>>>> >>>>> если оговаривать все в договоре, то договор можно писать 100 лет :) >> Мы заключали каждый раз дополнительные соглашения, коих накопилось >> более 100 в процессе работы. Часть из них пришлось оплачивать >> отдельно, часть признали входящей в условия заключенного договра
MC> И что ? Если вам по договору не выполняют оговоренных условий вы тоже MC> так ничего не делаете?
>>>>>>> В общем, это сейчас поплавав в ней 2 года мы понимаем что нас >>>>>>> обманули и очень сильно, но ничего уже не поделать. :( >>>>>>> MC>>>>>> Из ваших слов, пока видны проблемы реализации одного проекта, MC>>>>>> но какое это отношение имеет ЕРП системам в целом? >>> Отношение к чему или к кому?
MC> Какое отношение неудачи одного проекта имеют к тезису что "ЕРП системы MC> мешают управлять предприятием"?
они не мешают управлять, они даже помогают если нормально работают :) скажем так гемора стало больше, но и порядка тоже :)))
>>>> Менеджеры хотят в ней работать, все хотят в ней работать и >>>> работают но >>> извените меня когда топ менеджер читате отчте по приходу расходу >>> д/с за квартал с помесячной разбивкой, а у него сумму по >>> горизонтали не бьются т.е. янв -1 млн., фев. -1 млн., март - 1 млн, >>> итого по 1 кв 3,5млн и какая это управленческая информация?
MC> Точного ответа дать не могу :), но мне почему-то кажется, что этот MC> отчет готовился ручками.. ;) отчет готовиться в проге автоматически ;)))
>>> если честно то лично я реально просто устал воевать с внедренцами, >>> заявок написано кучи толка чуть, ребято просто включают дурочку. >>> не видели, повторите пожалуйста. если интересно могу показать их >>> отчеты по типу, ваш вопрос отправлне в Мск, ждите отвте. >> Ага. а как правило ответ нужен сегодня - чтобы сформировать отчетность >> для руководства. Знакомое поведение. понимаете когда на 10 поставленных вопросов следует 2 нормальных ответа - типа доработаем а на остальные вежливая посылка в МСК (читай на 3 буквы) >> >>>>> второе, что слишком мало мы знаем про эти системы, а кто знает >>>>> тот молчит в тряпочку Хочется в свою очередь узнать у кого >>>>> система внедрена и все хорошо. т.е. идет планирование и контроль >>>>> в полном объеме
MC> На сколько я знаю в фирме "Торговая Площадь" Аксапта была внедрена к MC> 2003 году и на тот момент большинство людей было довольно.., Вроде про MC> "Чип и Дип" и "МВО" ничего плохого не слышно.. А позвольте полюбопытствовать Вы с кем общаетесь в этих компаниях? потому как скажем наши производственники хотят притащить систему управления производством как на соседнем предприятии, она им очень нравиться, но я то общался с людми которые обслуживают ее и наполнят информацией и следят за правильностью, 1 день в неделю они ловят баги, да она для управленцев клад, ля простых людей не очень, но про них кто у нас думает :)
MC>>>> А вас при выборе системы внедренцы не возили показывать где MC>>>> такая система уже работает и как работает? >>> нет, только расказывали. Хотя мжет и были предложения, но я пришел >>> работь когда уже было принято решения было ТЗ и началось внедрение. >> Нам показывали элементы системы. И я с тех пор придерживаюсь мнения >> что MC> ну и на этих референсных площадках говорили что система плохая? тогда MC> почему вы ее выбрали? меня там не было :) когда я спросил а нафига (до этого я работал с 1С и все было как надо) мне сказали решение принято, ты могешь токо исполнять или быстро исполнять
MC>>>>>> Еще раз - не надо думать что ЕРП, КИС или еще какие буквы MC>>>>>> решит все ваши проблемы, сразу после того, как вы заплатите MC>>>>>> деньги.. Внедренцы не решают вопросы управления капиталом, они MC>>>>>> только настраивают инструмент, так как это записано в MC>>>>>> техническом задании.. Задача адекватно написать ТЗ эта задача MC>>>>>> общая для внедренцев и клиентов.. >>> оно написанное. но если яне могу верить в формируемые отчеты как я >>> могу эфективно управлять ресурсами? если видя оплату опять таки >>> миллион и зная план оплаты то нужно платит 3, я делаю прогноз что >>> нужно доплатит будет 2, а фигушки цифра про 1 млн правильная а вот >>> про 3 вранье там 3,5 :)
MC> ИМХО, не знаю точного ответа, но мне кажется, что данные человек MC> подправляет ручками, причем только часть данных а не все, часть этих MC> подправлений попадает в ваш отчет, а часть нет... . еще раз говрю отчеты руками не правяться :) они формируются на основании первички (той или иной)
>>>>> И в чем тогда проблема? ТЗ написано, мы его выполняем, осталось >>>>> добиться выполнения от внедренцев, но ни же не взяли с нас деньги >>>>> за то что не выполнили и это как они считают честно. >>> MC>>>> А если кто-то не выполнит договор, по которому вы заплатили MC>>>> существенные деньги вы требовать деньги обратно тоже не будите? MC>>>> странно, что тогда вы, как компания еще существуете ;) >> Исполнитель работ отчитывается по выполненным этапам, которые >> подписаны заказчиком. подписание всех этапов - ознакает завершение >> контракта и выполнение обязательств
MC> Этап выполнен, если реализованы все элементы ТЗ на этот этап.. Пишите MC> в акте, что такие-то пункты ТЗ не реализованы, оплата за этот этап MC> работ будет осуществлена после устранения замечаний...
>>> их как раз проинформировали очень красочно, по факту получилось не >>> очень :), но если моего начальника не очень это коснулось, т.к. вся >>> выловка ошибок лежит на мне, то вот главбух она страдает потому как >>> ошики ей ловить приходиться самой :) >> Легче всего внедренцам ничего не знающему начальнику объяснить что >> все в шоколаде - не ему же работать в системе, ему лишь только >> отчеты получать. Может
MC> Ну если начальник ничего не знает, то он плохой управленец ;), а
MC> вопросы, связанные с ошибками управления никакая система решить не MC> позволит.. до него иногда доходят отголоски ну и что он может сделать? ответ известен, мы направили в Мск там разобрались и предложили установить новую версию, да мы совершенно точно знаем что у вас престанут работать половина отчетов но за 500р в час мы вас снова спасем :)))
>> быть поэтому внедренцы так любят общаться с высшим руководством и >> требуют его поддержку, а не с непосредственными операторами работы в >> системе? Всегда же можно объяснить что персонал не подготовлен, что >> руководство стратегически мыслит, а вот его персонал-подчиненные >> саботируют работу, глупые и не могут освоить элементарные вещи. >> Систему надо рассчитывать на среднего клерка, которому работать в >> системе а не на его начальника.
MC> Клерк проверил при подписании акта что система работает? что отчеты MC> формируются и формируются правильно? если так и никто в систему не MC> вносил изменений, то очень странно что система формирует в разное MC> время разные отчеты.. как я могу проверить отчет без данных? я проверил что он есть и формируеться, это был месяц 2-3 работы в программе, было заведено инфы по минимуму, все болше начальными остатками, бвги пошли когда началась работа.
-- Ф¨дор
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4351 от 2007-02-14 участников 1923 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Продолжаем разговор :))))))
Я пока не против %)
>>> какой может быть вопрос если человек 2 месяца назад занес сумму >>> оплаты материалов по договру и с тех пор эта сумма не изменялась? > Данные берутся из проведнных в учет документов, все доки живут на > счеах по направлениям. например материалы. там отражено все списание > материалов в разрезе договоров, номенклатуры и т.п. Вы можете > возразить что какойдо деверсан взял и сменил скажем направление > списаним, т.е. номер договора, а вот и нет, если отсотировать все > списание по договрам то цифра не бьется с отчетной :))))
Чудеса у вас.. Среди отмазок слышал еще такую: " при формировании отчета (запроса данных от удаленной машины) - витую пару передергивали? да - ну вот один договор в момент передергивания был отправлен, но не был получен - то есть потерялся"
MC>> В целом, согласен что не все может быть описано, но если что-то MC>> написано, то внедренцы имею право эти требования понимать > буквально.. > а отмазки типа у вас сетевые провода криво положены потому отчет > неработает, как вам? конечно утрированно, НО. были постоянные зацепы > на нецензионное ПО неграмотно построенную локальную сеть, вирусы и > т.д и т.п. вплодь до того что компьютер не той конфигурации, ну и > что что он отвечает требованиям программы заявленным в инструкции
Если в ТЗ на тех средства не прописано каким концом провод втыкать - требования внедренцев идут лесом.. Хотя, если до этого доходит то это уже не проект по внедрению, а проект по перекладыванию ответственности...
>>> Именно об этом и я пытался сказать, но как видите - есть мнение, что >>> клиента надо доить, раз он дурачок - вот нас и доят - это же бизнес! >>> Боюсь только что такой бизнес умрет, не родившись толком. > MC>> Ну наличие большого количества Элексиров на рынке говорит об MC>> обратном... ;) > У нас не только рынок ПО так построен
Я бы даже сказал что почти любой рынок так построен...
>>>>>> Разработчики сказали - сделаем! Второе пожелание было >>>>>> обеспечить возможность внесения изменений задним числом в >>>>>> управленческую информацию. >>>>> В общем, это сейчас поплавав в ней 2 года мы понимаем что нас >>>>> обманули и очень сильно, но ничего уже не поделать. :( >>>>> MC>>>> Из ваших слов, пока видны проблемы реализации одного MC>>>> проекта, но какое это отношение имеет ЕРП системам в целом? >>> Отношение к чему или к кому? > MC>> Какое отношение неудачи одного проекта имеют к тезису что "ЕРП MC>> системы мешают управлять предприятием"? > > они не мешают управлять, они даже помогают если нормально работают > :) скажем так гемора стало больше, но и порядка тоже :)))
О, таки то что и нужно было - система показала (помогла выявить) те места на которые забивали, потому что их было не видно, теперь приходится напрягаться...
>>>> Менеджеры хотят в ней работать, все хотят в ней работать и >>>> работают но >>> извените меня когда топ менеджер читате отчте по приходу расходу >>> д/с за квартал с помесячной разбивкой, а у него сумму по >>> горизонтали не бьются т.е. янв -1 млн., фев. -1 млн., март - 1 >>> млн, итого по 1 кв 3,5млн и какая это управленческая информация? MC>> Точного ответа дать не могу :), но мне почему-то кажется, что MC>> этот отчет готовился ручками.. ;) > отчет готовиться в проге автоматически ;)))
MC>> На сколько я знаю в фирме "Торговая Площадь" Аксапта была MC>> внедрена к 2003 году и на тот момент большинство людей было MC>> довольно.., Вроде про "Чип и Дип" и "МВО" ничего плохого MC>> не слышно..
на Площадке давно это было, в 2003 - с инициатором проекта, кажется исполнительным директором, в "МВО" - со специалистами, которые проект делали.. Скажем так, если бы там были бы серьезные проблемы то я бы про них слышал, раз не слышал, то скорее всего там более-менее нормально.. Если есть интерес, то попробуйте к ним напрямую обратиться, или в Коламбус - поинтересуйтесь их успешными проектами, по крайней мере они должны сказать про то, что им не стыдно показать..
> А позвольте полюбопытствовать Вы с кем общаетесь в этих компаниях? > потому как скажем наши производственники хотят притащить систему > управления производством как на соседнем предприятии, она им очень > нравиться, но я то общался с людми которые обслуживают ее и наполнят > информацией и следят за правильностью, 1 день в неделю они ловят > баги, да она для управленцев клад, ля простых людей не очень, но про > них кто у нас думает :)
Ну так а кому сейчас легко :)), систему внедряют, чтобы инициатор решил свои проблемы, а простым людям работы всегда добавляется %)
MC>>>>> А вас при выборе системы внедренцы не возили показывать где MC>>>>> такая система уже работает и как работает? >>>> нет, только расказывали. Хотя мжет и были предложения, но я >>>> пришел работь когда уже было принято решения было ТЗ и началось >>>> внедрение. >>> Нам показывали элементы системы. И я с тех пор придерживаюсь >>> мнения что MC>> ну и на этих референсных площадках говорили что система плохая? MC>> тогда почему вы ее выбрали? > меня там не было :) когда я спросил а нафига (до этого я работал с > 1С и все было как надо) мне сказали решение принято, ты могешь токо > исполнять или быстро исполнять
Еще один аргумент, что проект этот был сделан не совсем как надо %))
MC>> Клерк проверил при подписании акта что система работает? что MC>> отчеты формируются и формируются правильно? если так и никто в MC>> систему не вносил изменений, то очень странно что система MC>> формирует в разное время разные отчеты.. > как я могу проверить отчет без данных? я проверил что он есть и > формируеться, это был месяц 2-3 работы в программе, было заведено > инфы по минимуму, все болше начальными остатками, бвги пошли когда > началась работа.
Возьмите тестовую база, при проверке добавьте еще один первичный документ, если отчет изменился так, как вы и планировали, тогда скорее
всего система работает адекватно. Да, это значительная работа со стороны Клиента, ну так ведь и читается что ключевые специалисты со стороны клиента 50% рабочего времени должны тратить на работу по системе :)
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4352 от 2007-02-14 участников 1923 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Газета "Компьютерные Вести" (Беларусь) No1, 2007 год Оригинал: http://kv.minsk.by/index2007011105.htm
Автор: Артем ПРОКСИН Иронические заметки автоматизатора Как "советуют" выбирать программу для автоматизации
> Предисловие
По роду своей работы - руководство проектами по автоматизации предприятий - мне приходится довольно часто участвовать в обсуждении вопросов "Нужно ли приобретать ту или иную программу?" и "Какую именно программу следует выбрать?".
Большое количество рекомендаций на эту тему можно найти в специа- лизированных изданиях и на соответствующих сайтах в интернете. Но есть среди них и такие, которые внешне выглядят, вроде, вполне разумными, но в реальности ведут, что называется, "в никуда".
Вот и недавно попались под руку материалы одного из семинаров с такими "советами", которые и стали поводом для написания этого иронического экспромта, с точки зрения участника с другой стороны процесса автоматизации.
> "Бизнес-цели" или начало выбора
Для начала будущему пользователю программы в лице руководства предприятия рекомендуется определиться с целями. Цитирую:
"Начните с определения бизнес-целей, которые должны быть: o Конкретными o Имеющими денежное выражение o Детализированными
Как это может выглядеть: o Оцените ваш план развития o Оцените рынок и стратегию работы на нем o Определите текущие проблемы o Определите причины, их вызывающие".
В общем, перед тем, как выбрать программу, надо сделать "самую малость" - разработать всю стратегию работы предприятия!? Очень похоже на "стрельбу из пушек по воробьям". Что же теперь, каждый раз при покупке новой программы строить "планы" и "стратегии"? В нормальной компании такие планы есть изначально, и новые инструменты лишь вписываются в существующую стратегию.
Реально же программы автоматизации приобретаются чаще всего в двух случаях: 1. Когда уже очевидно, что без такой программы не обойтись - компания либо теряет доходы, либо хочет их увеличить. 2. Когда такие программы уже есть у конкурентов - это верный признак того, что пора перестать комплексовать по поводу "экономической целесообразности" и отнестись к автоматизации как к "осознанной необходимости".
> Шаг второй - критерии выбора
В этих же материалах даются рекомендации по формированию критериев выбора. В частности, рассматривается "Соответствие запрашиваемой функциональности". Т.е., имеется в виду, насколько функциональность программы соответствует потребностям заказчика.
Список рекомендаций по этому поводу выглядит следующим образом: o "Составить полный список необходимых функций с указанием приоритетов (или этапов) и сложности реализации - shopping list. o Попросить поставщиков указать - какие из функций входят в базовую функциональность, какие требуют доработки. o Сделать сквозной анализ каждой функции".
Подобные "рекомендации" кочуют по разным семинарам и пособиям. Внешне, как уже говорилось, они выглядят вполне логично и разумно.
Но на практике оказывается, что составить "полный список необходимых функций" дело очень не простое, если не сказать совсем не выполнимое.
А ведь здесь еще рекомендуется и указать "приоритеты", и "сложность реализации", и "сделать сквозной анализ каждой функции"!?
> Техническое задание - финиш или начало движения?
Приведем образец такого списка функций, составленного в одной из компаний, оказывающей услуги по ремонту автомобилей.
"Программа для диспетчерской"
o Каждый оператор работает под своим именем и паролем o Программа предоставляет возможность получения следующих отчетов: o Отчет по дате выполнения заказа o Отчет по клиенту (ФИО, юридическое или физическое лицо) o Отчет по водителю o Отчет по оператору o Отчет по марке, модели, году выпуска а/м o Отчет по месту нахождения а/м o Отчет по месту назначения o Отчет по гос.номеру машины o Отчет по сумме услуги o Отчет по видам услуг (техн. помощь, эвакуация, информация) o Отчет по машинам, выезжающим на оказание услуг o Отчет по партнерам (город, регионы) o Возможность предоставления отчета за месяц, квартал, год o Возможность поиска по любому пункту o Заполнение заявки в компьютере. Предусмотреть: исполнена, отмена. А в графе "примечание" объяснение причины отмены".
Если кто-то думает, что, составив такое ТЗ, он уже выполнил свою задачу, и остальное - дело программистов, то он глубоко ошибается.
Здесь работа только начинается. Надо, как минимум, расписать детально все отчеты и продумать для этой верхушки айсберга всю ее подводную часть - систему ввода, хранения и извлечения информации.
Но самое главное, что настоящую постановку задачи ни заказчик, ни исполнитель не смогут выполнить по отдельности. Какими бы "профи" не были сотрудники организации-исполнителя, им все равно не обойтись без привязки программного продукта к специфике деятельности предприятия. И, наоборот, какими бы подробными не были описания бизнес-процессов предприятия, они не могут один к одному налагаться на внутреннюю архитектуру программного продукта.
> Некоторые мифы о том, как "надо выбирать программу"
В дополнение к вышеприведенным "советам" взглянем изнутри и на некоторые мифы, сопровождающие выбор корпоративного ПО.
_Миф 1_. Дайте демо-версию
Некоторые пользователи перед покупкой программы настаивают попробовать ее в демо-версии. Представляется, что тот, для кого программа покупается, попробует с ней поработать в свободное время и поймет, подходит она ему или нет.
На самом деле, во-первых, если времени нет сейчас, то его не будет и потом. Во-вторых, не зная программу, а корпоративные системы не такие простые, как, например, ISQ, пользователь понажимает пару кнопок и бросает это дело. Наконец, корпоративные системы очень редко бывают стандартными. Практически всегда их необходимо настраивать под конкретного клиента.
А поскольку в демо-версиях таких индивидуальных настроек нет, то и программа кажется чужой, не удобной, которая не подходит под потребности компании.
_Миф 2_. Где работает ваша программа, как на нее посмотреть?
Еще один "верный" способ решить вопрос.
Представляется, что соберутся несколько человек - главный бухгалтер, коммерческий директор, программист - и поедут к клиенту, у которого такая программа уже работает. Там они побеседуют с пользователями, узнают от них "правду" о программном продукте, о разработчиках, о том, как они обслуживают пользователей и т.д.
Любители таких проверок не очень задумываются, как будет выглядеть их визит с точки зрения другой компании. Хозяевам нужно оторваться от своих дел, организовать прием гостей, тратить на них свое время, что-то им рассказывать, чему-то их учить и т.д. И опять же, в лучшем случае, если их пустят в чужую организацию, гости увидят чужую программу. А если это не похожая программа, то чем она будет полезна? А если похожее предприятие, то это, скорее всего, конкурент, а кто же будет учить конкурента вести дела?
Еще одну точку зрения выразил генеральный директор производственного предприятия, внедрившего недавно "1С 8.0 УПП": "А зачем мне просто так рассказывать о том, за что я заплатил деньги?".
_Миф 3_. Сколько лет вы работаете на рынке?
Некоторым заказчикам кажется, что таким хитрым вопросом они обезопасят себя от фирм-однодневок.
Не говоря уже о том, что такие сведения трудно проверить (практически любая фирма может найти свои "исторические корни") и что этот вопрос больше для самоуспокоения, здесь еще есть и другая, более серьезная причина.
Если вы ориентируетесь только на компании, которые работают на рынке "10 лет и больше", то вы рискуете прозевать новые разработки и купить то, что может через год морально и технически устареть.
> Притча о "пинчере"
И в заключение притча из программистского фольклора.
"Однажды один человек пошел на рынок, чтобы купить себе собаку-пинчера. Он ходил от одного продавца к другому и спрашивал: "У вас есть пинчер?" Но ни у кого из продавцов пинчера не оказалось.
Так он проходил целый день и пошел с рынка ни с чем. Сразу за воротами сидел бомж. Он увидел грустного человека и спросил у него: "Что ты ищешь?". "Пинчера", - ответил человек. И тогда бомж протянул ему то, что держал в руках, и сказал: "Вот, пинчер"...
> Мораль сей басни
Мораль сей басни такова: рынок корпоративного ПО сегодня - это рынок продавцов, где спрос существенно превышает предложение. И вряд ли кто из компаний-исполнителей будет разрабатывать новую бухгалтерскую или ERP-систему под заказ. Даже в проектах для крупных организаций стараются подобрать уже готовый программный продукт в качестве базовой платформы. Поэтому не стоит относиться к приобретению программного обеспечения как к простой и разовой акции. Это процесс, который нужно будет поддерживать на всем протяжении жизненного цикла предприятия.
Кроме того, по своей значимости автоматизация предприятия уже не уступает таким важным вопросам, как бухгалтерия и кадры.
Но самое главное: приобретение ПО не может строиться по схеме, где заказчик просто платит деньги, а исполнитель за эти деньги исполняет все его прихоти. Решающим моментом в успехе проектов по автоматизации является нахождение взаимопонимания между обеими сторонами.
В противном случае компания рискует купить "пинчера". -*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4354 от 2007-02-14 участников 1921 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Доброго времени суток!
Дмитрий, спасибо. Эта статья - хорошее резюме дискуссии, перешедшей в разряд дискуссии не о чем.
Наблюдая за этим диспутом я укрепился во мнении: -
1) Автоматизируется то, что в мозгу у заказчика-инициатора автоматизации (далее ЗИА) - грезы!
2) Если ЗИА не в состоянии четко и детально сформулировать тот процесс, который он хочет автоматизировать, то ЗИА не представляет зачем ему нужна автоматизация,.. да и сам процесс не представляет себе. Если ЗИА топ-менеджер/владелец фирмы - то он не представляет себе подконтрольный бизнес. И автоматизация ему нужна как вариант божией помощи: до этого ходил в церковь молиться-просить у бога успеха бизнесу и на храм жертвовал; теперь решил с программерам-внедренцем пообщаться и на их благое дело компьютеризации денег пожертвовать.
3) Если ЗИА в состоянии устно сформулировать то, зачем ему автоматизация (или записать это не отрывая руки от бумаги, за один присест); то ЗИА и автоматизация не нужна (он все и без нее прекрасно представляет и владеет своим бизнес-процессом). Вот и выходит, что ЗИА уже и не ЗИА :-)
P.S.: в который раз вспоминаю тезис сторонников Зенона: - нельзя и один раз войти в одну и ту же реку... :-)))) Неужели найдутся умельцы, способные в случае с программным обеспечением теоретически/логически (диск.лист позволяет только теоретически) обосновать то, что Геркулес способен обогнать черепаху? -- С уважением, Дмитрий Ковал¨в -*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4356 от 2007-02-15 участников 1917 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Уважаемые господа! Наша дискуссия распалась на множество отдельных "сражений". Что касается невыполнения условий договора, о чем писали и Федор, и Максим, то способы борьбы с этим различные в каждом конкретном случае. Я сам мучался более 0.5 года при разработке системы материального снабжения на Clipper 5. Иногда не "бились" цифры разных отчетов, полученных из одних и тех же исходных данных. Причина оказалась в ошибках самого Clipper'а. Но крови попортила и мне, и заказчикам много. Если в таких случаях ваши внедренцы не могут решить проблему сами, а ссылаются "на Москву", то это не очень квалифицированные внедренцы и с ними лучше по серьезным темам не работать. И вообще, лучше всего иметь свою группу разработки с хорошими программерами и разработчиками. О причинах я уже писал.
Если же говорить о возможности внедрения ERP "вообще", то нужно вспомнить анекдот про грузина, который искал в Москве магазин Принцип ("в принципе все есть"). Так вот, в принципе, внедрить ERP возможно. Если есть средства, время, люди и очень большое желание. Вот только методика внедрения, на мой взгляд, должна быть очень строгой. Чтобы понять, какой именно, и обосновать ее, давайте вспомним, с чего начинался ERP - с планирования потребности в материалах (MRP - Material Requierment Planning). Вот и начинайте с этого! Со справочников материалов и комплектующих, с наведения порядка в их закупе, учете на складах и в производстве. Вот когда это все заработает как часы, переходите к разработке следующей системы - MRPII (Manufactory Resource Planning, планирование потребности в ресурсах), расширяющей возможности УЖЕ СУЩЕСТВУЮЩЕЙ у вас системы MRP. И далее к расширению MRPII до ERP. Разработать (даже на уровне ТЗ) систему класса ERP с учетом всех существующих (и возможных в будущем!) потребностей и требований абсолютно нереально. А уж сделать это под ваши конкретные (зачастую даже и не до конца самими понимаемые) потребности силами сторонних разработчиков - и вовсе из области мечтаний.
-- С уважением, Владимир
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4357 от 2007-02-15 участников 1917 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
И продолжая начатое мной письмо о возможности разработки и внедрения ERP, уточню касательно платформы и разработчиков. Все, кто уже писал по этим вопросам в ДЛ - и Максим, и Алексей, и оба Дмитрия (Ковалев и Славников) сходятся в одном - рассчитывать на глубокое понимание ваших проблем сторонними разработчиками по меньшей мере наивно. Разработать для них ТЗ на все случаи жизни на ...цать лет вперед - нереально. Вывод один - делайте силами своих разработчиков с возможным соучастием сторонних в качестве консультантов. Отсюда и следующий вывод, о котором я тоже уже писал, - выбирайте максимально простую в понимании и освоении платформу, на которую достаточно легко найти специалистов и которая хорошо поддерживается разработчиками. И которая достаточно много делает уже до вашего грубого вмешательства! Ради Бога не подумайте, что я рекламирую какую-нибудь 1С (хотя именно это я и делаю). По крайней мере это наиболее реально может дать конкретный (не идеальный) результат. -- С уважением, Владимир
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4360 от 2007-02-16 участников 1913 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
С немалым удивлением читаю все приходящие "письма". Их видимо пишут люди у которых много свободного времени. Хотел сразу отказаться от подписки, но подумал - "это же мои коллеги". Отвечу сразу, опираясь на профессиональный опыт программиста, экономиста, менеджера и внедренца. Современное состояние программных инструментов такое, что автоматизировать свою работу в состоянии сам заказчик. Выбирается любая базовая учетная система, ориентированная на бух учет, без всяких дополнительных и не нужных наворотов. Ставится и начинается сбор основной информации. Все остальные задачи реализуются простыми программными средствами с которыми современные экономисты и менеджеры хорошо знакомы с ВУЗа ( к примеру ACCES). Через средства OLE информация напрямую выбирается из 1С, дополняется недостающей, из базы ACCES производятся расчеты и прочие вещи. При такой технической компоновки система получается гибкой, и очень оперативной с точки зрения решения задачи ВОПРОС-ОТВЕТ. И самое главное, систему создает сам коллектив работников. По роду свой работы, как главного менеджера компании, мне приходилось возглавлять небольшие фирмы где работают несколько десятков человек, до компаний, где несколько тысяч. И везде при данном подходе, руками местных экономистов и менеджеров (при небольшой помощи специалистов для написания программ прямого обращения в базовую систему (1С например), через 2-3 месяца рождалась систему управления компанией, как с формальной точки зрения, так и со стороны автоматизации. А в итоге через 4-5 месяцев на предприятии функционирует система включающая и систему управления индикаторами целей, сбалансированными показателями развития, автоматизация управления основными участками производства и пр. И нет у нас никаких дебатов, кто должен и кто виноват когда ни чего не получается. Все очень просто.
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4361 от 2007-02-16 участников 1913 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> А в итоге через 4-5 месяцев на предприятии > функционирует система включающая и систему управления индикаторами > целей, сбалансированными показателями развития, автоматизация > управления основными участками производства и пр. И нет у нас никаких > дебатов, кто должен и кто виноват когда ни чего не получается. Все > очень просто.
Все очень просто, да не совсем. ;-)
Вся кажущаяся простота, на мой взгляд, сводится к следующему:
1) Вы, как главный менеджер, представляете, в каком направлении и как должна развиваться компания.
2) Вы представляете, какая Вам нужна информация для управления развитием компании в данном направлении.
3) Исходя из первых двух пунктов Вы, как главный архитектор системы, представляете, какая необходима система управления компанией.
4) Вы можете четко описать, что и в какой последовательности нужно делать, чтобы такую систему создать.
5) Вы, как гоавный менеджер проекта, умеете управлять достижением поставленной цели.
И где же здесь просто? Это очень даже не просто, о чем и свидетельствует вся эта дискуссия. ;-)
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4363 от 2007-02-16 участников 1913 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Современное состояние программных инструментов такое, что > автоматизировать свою работу в состоянии сам заказчик.
Если у Заказчика есть такие специалисты, то да? он сам может.. Но есть аргументы за внешних специалистов: 1. они "равно удаленные от внутренних точек интересов Заказчика" 2. они за счет специализации (наличия базы знаний по предыдущим аналогичным проектам) могут эту самую работы сделать быстрее и дешевле чем заказчик
> Выбирается любая базовая учетная система, ориентированная на бух > учет, без всяких дополнительных и не нужных наворотов. Ставится и > начинается сбор основной информации.
Как правило такая система уже есть - 1С.
> Все остальные задачи реализуются простыми программными средствами с > которыми современные экономисты и менеджеры хорошо знакомы с ВУЗа ( > к примеру ACCES).
На счет "хорошо знакомы" это некоторый оптимизм ;)
> Через средства OLE информация напрямую выбирается из 1С, дополняется > недостающей, из базы ACCES производятся расчеты и прочие вещи.
А почему 1С первична? только потому что она уже есть? а что делать если в 1С информация попадает к концу месяца (как нужно бухгалтерам), а управленческая отчетность нужна послезавтра?
> При такой технической компоновки система получается гибкой, и очень > оперативной с точки
Гибкость не всегда хорошо, ибо гибкость противоречит наличию устоявшихся стабильных процедур, которые стоит автоматизировать..
> в базовую систему (1С например), через 2-3 месяца рождалась систему > управления компанией, как с формальной точки зрения, так и со > стороны автоматизации.
Мы,в рамках этого топика рассматриваем ЕРП, а не учетную систему, в бухгалтерских системах я не встречал блока планирования загрузки и учета мощностей, так как они не интересны бухгалтерам... Если стоит задача, автоматического сбора информации по осуществившимся операциям, то такую систему за 3-4 месяца поставить реально...
> А в итоге через 4-5 месяцев на предприятии функционирует система > включающая и систему управления индикаторами целей, > сбалансированными показателями развития, автоматизация управления > основными участками производства и пр. И нет у нас никаких дебатов, > кто должен и кто виноват когда ни чего не получается. Все очень > просто.
Если у вас нет проблем, и вы успешная компания, то ЕРП и КИС внедрять вам не стоит :)
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4364 от 2007-02-16 участников 1913 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
>> А в итоге через 4-5 месяцев на предприятии функционирует >> система включающая и систему управления индикаторами целей, >> сбалансированными показателями развития, автоматизация управления >> основными участками производства и пр. И нет у нас никаких дебатов, >> кто должен и кто виноват когда ни чего не получается. >> Все очень просто.
> Все очень просто, да не совсем. ;-) > свидетельствует вся эта дискуссия. ;-)
Вот и получается, вся проблема с проблемами ЕРП :-) связана исключительно с проф.компетенцией главного менеджера; а не сторонних внедренцев и консультантов. "Разруха, батенька, она в головах, а не в стране" (Булгаков. "Собачье сердце", проф.Преображенский).
-- С уважением, Дмитрий Ковал¨в
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4365 от 2007-02-16 участников 1913 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Все очень просто, да не совсем. ;-) > И где же здесь просто? Это очень даже не просто, о чем и > свидетельствует вся эта дискуссия. ;-)
Просто, каждым делом должен заниматься специалист. Если меня попросит отремонтировать электропроводку в доме, это будет надолго, дорого и наверно плохо, и в конце концов придет электрик и все сделает как надо. А суть нашего подхода чуть в другом. Предложенная технология реализации задачи,позволяет исключить программиста, как звено и все связанные с этим проблемы. Не четкое понимание задачи между постановщиком и программистом, что приводит к удлинению сроков и ухудшению качества. А так же обеспечение живучести системы при смене программистов, что при традиционном подходе чревато последствиями. Просто, все о чем вы пишите, все это пройденные трудности на которые давно есть простые и стандартные решения. Так что, если есть проблемы, пишите Поможем советом из нашего опыта.
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4366 от 2007-02-17 участников 1902 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> С немалым удивлением читаю все приходящие "письма". > ................ [ В Ы Р Е З А Н О ] ................... > Все очень просто.
Не все так просто. У нас, например, производительности 1С не хватает. Выписку накладных приходится осуществлять в самописной программе. И вопрос не в получении цифр, а в ускорении процесса, без сбоев и накладок
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4367 от 2007-02-17 участников 1902 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> С немалым удивлением читаю все приходящие "письма". Их видимо пишут … > просто.
Согласна с Вами, уважаемый Хочешь сделать хорошо - сделай сам. Но в небольших коллективах и даже если около 500 человек общей численности,штат далеко не всегда готов не только поставить себе ТЗ на каждое рабместо, но даже использовать уже поставленные решения. Потому находится достаточно много работы для чужих внедренцев и программистов,а если свои не поставят задачу грамотно,то как посторонние смогут ее правильно решить.
-- Елена.
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4368 от 2007-02-19 участников 1900 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Доброго дня ,
17/02/2007 Елена писала: >> С немалым удивлением читаю все приходящие "письма". Их видимо пишут … >> ни чего не получается. Все очень просто.
Позвольте не согласиться, это что получается хочешь быть здоровым лечись сам, сам себе аппендиксы вырезай, хочешь кушать вкусно готовь сам,животных сам выращивай, картошку сам сажай, так дело не пойдет. а по поводу быстрого и легкого внедрения, вопрос ведь в том какие данные нужно было собственникам. одним моим хватала суммы месячной прибыли, у них была планка и если цифра выше ее то гуд, ниже, давайте будем разбираться и все. тут заавтоматизировать как нечего делать аж на калькуляторе ;)
-- Ф¨дор -*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4369 от 2007-02-20 участников 1891 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Уважаемые коллеги, > в процессе нашего обсуждения мы забыли про одно весьма важную вещь. … >
Поддерживаю. От себя еще добавлю следующее. На сегодняшний день многие разработчики согласны, что нужны 2 ключевых специалиста - бизнес-аналитик и системный аналитик.
Бизнес-аналитик описывает предметную область, строит бизнес-модель и систематизирует бизнес-процессы. Системный аналитик проектирует архитектуру программы.
И делают они не один документ, который ТЗ, а два. Один я называю постановка задачи, где описывается предметная область, и второй - собственно ТЗ, где уже описывается в технических терминах сама программа.
Хотя на самом деле этих документов больше, поскольку есть еще общий план работ, а в нем обязательно отдельный план внедрения, где учитываются установки, обучение, настройки, перенос данных, опытная эксплуатация и т.д. Плюс еще финансовый план. Это в основном.
И далее есть несколько важных замечаний. Во-первых, бизнес-аналитик чаще всего бывает все-таки со стороны разработчика. Со стороны заказчика хорошо когда он есть, а еще лучше, когда у него есть опыт построения и внедрения ИТ-систем. А еще проще говоря, когда он продвинутый пользователь ПК или в прошлом программист. Таких кстати довольно много в компаниях.
Обычно бывает так, что отвечает за проект кто-то из замов генерального, например коммерческий директор, плюс у него свой зам по ИТ-проекту, это или нач АСУ или просто местный сисадмин.
Второе, очень существенное. Описание бизнес-модели сегодня зачастую сводят к какой-то пояснительной записке, либо к механическому перечислению функций пользователей. Не спасает применение средств их графического отображения типа IDEF0 и тому подобного. Строятся диаграммы с погружением от одного уровня до следующего, от процесса к действиям и функциям и к операциям.
В итоге, понять весь этот ворох схем может только тот, кто их нарисовал, а удержать все в голове не может и он.
Здесь нужно идти не от механического деления на мелкие элементы, а на смысловые описания, отталкиваясь от понимания бизнес-процессов у Майкла Хаммера в его бессмертном реинжиниринге. На самом деле этих бизнес-процессов всего 5-6 и нужна лишь определенная схема их описания, которая будет понятна заказчику.
Третье, следующий этап - эти описания бизнес-процессов накладываются на программное обеспечение. Если быть уж совсем точным, то на основании этого описания и выбирается базовый софт, то ли SAP, то ли Baan, который сейчас неожиданно возродился, то ли Oracle, который в последнее время очень агрессивно активизировался, то ли Галактика, то ли 1С и т.д.
Попутно тоже существенное примечание, что сегодня заново системы практически не пишутся, только в отдельных случаях либо на очень крупных проектах, либо наоборот на очень мелких. Все остальные берут готовую платформу и подстраивают ее под себя, либо подстраиваются под нее. Это зависит от размера кошелька, причем второй вариант как раз таки дороже :)
Процесс наложения бизнес-процессов на софт показывает, что в софте есть, а что надо настроить, изменить, доработать и т.д. В 1С это называют методикой разрывов. Список этих разрывов и есть основа ТЗ. Руководителю проекта остается только пояснить все эти задачи программисту.
Но, очень и очень важное. Описание бизнес-процессов и описание программы не симметричны друг другу. Почему сейчас и говорят об объектно-ориентированном программировании. Если раньше думали, что достаточно описать функции, действия пользователей, составить на этой основе ТЗ и потом просто это реализовать, то потом поняли, что это невозможно.
И невозможно по одной простой причине - архитектура программы не совпадает с архитектурой бизнеса! И бизнес, и программа есть некие системы, которые состоят из определенных элементов, или объектов. Это достаточно самостоятельные элементы, имеющие определенную смысловую целостность и выполняющие определенный набор функций, посредством которых они взаимодействуют с другими объектами.
Я это потому так ударился в теорию, чтобы теперь показать, что в программе есть элементы которые совпадают с элементами бизнеса, из-за которых и возникает ложное ощущение их похожести. Но есть отличающиеся элементы. Например, первые программы автоматизации просто копировали бумажные документы, типа платежки, накладной и т.д. Этот элемент есть и теперь - это документы. Есть там и там и отчеты.
Но вот понятие справочника как элемента с относительно постоянной информацией есть только в программе, в бизнесе его только за уши можно притянуть.
Самое главное из этих разговоров о непохожих системах - это переход из одной системы в другую. Т.е. должен быть специалист который грамотно прочитает описание бизнес-процессов и также грамотно составит техническое описание программы (или ее доработок).
Который видя, например, описание бизнес-процесса "отгрузка продукции", будет знать, какие в нем участвуют со стороны программы объекты - справочники, документы, регистры, обработки, отчеты и т.д.
Причем, на практике чаще всего получается так, что это делают именно два человека - все те же бизнес-аналитик и системный аналитик. Один хорошо знает бизнес и неплохо программу, второй наоборот неплохо знает бизнес и хорошо знает программу.
И последнее и самое важное. Все что сказано ранее - это всего лишь частные детали более общего процесса. Он включает в себя две глобальные переменные - общий подход к реализации всего проекта и работу по внедрению, которая составляет порядка 2/3 всех работ и на которую начали обращать внимание лишь в последнее время.
Два слова об общем подходе к реализации проекта. Очень правильно здесь говорилось, что на первом этапе нужно обследование и ТЗ. Но есть две проблемы.
Первая - заказчик не хочет платить за бумажки. У нас был однажды такой анекдот - расписали заказчику всю работу, первый этап обследование, второй - настройка программы и т.д. Он посмотрел и говорит, хорошо, все устраивает, только можно без обследования? :)
Если быть принципиальным, т.е. требовать обследования, заказчик может уйти к другим и купить как в той статье пинчера.
Выход - делать обследование не выпячивая его, по ходу первых работ.
Вторая проблема - тратить очень много времени на обследование и ТЗ, делать его очень подробным и записывать это все в договор и прочие бумаги - замучаешься. Но самое главное - это все равно не спасет, все равно что-то будет упущено, понято не так и т.д. и т.п. Более того, пока все это будет реализовываться многое изменится и все эти бумажки окажутся ненужными.
Разработчики не дадут мне соврать, что большинство изменений появляются у пользователей тогда, когда начинается непосредственная работа с программой. Именно тогда они вдруг видят, что где-то там не хватает кнопочки, а вот здесь надо такие-то цифирки, и что все это говорилось или подразумевалось в ТЗ, и что без этого выполнение этой операции бессмысленно и поэтому оно-то и подразумевалось и должно быть выполнено без дополнительной оплаты и т.д. и т.п.
Самое удивительное, что он прав, но только в том смысле, что заранее все это предусмотреть невозможно.
Поэтому, возвращаясь к общему подходу в реализации проекта, нужно идти по спирали, по итерациям. Т.е. быстро делаем общий план, видим общую картину, выделяем ключевые позиции, составляет план первоочередных задач. Реализуем первый этап, подводим итоги, анализируем, корректируем при необходимости общий план, делаем план на второе этап и двигаемся дальше. И ничего страшного если все будет идти не по прямой линии, последовательно, а кругами - сегодня это делали в связке с одними задачами, завтра то же, но уже в другой цепочке хозяйственных операций. Ничего страшного, если завтра вдруг обнаружится, что на первых этапах что-то пропустили или прозевали. Все не предусмотришь. Но первый общий план многие риски уменьшит, это однозначно. Когда-то прочитал в рекомендациях Microsoft - не старайтесь на первых этапах прописать все задачи вглубь, главное в начале пройтись вдоль, вширь, зацепить все вопросы на верхнем уровне.
Очень важно, чтобы это понимал и с этим согласился заказчик. Я знаю, мне скажут, а что делать если заказчик, например, душит - назовите сроки и цену. Есть очень хороший ответ - для того чтобы это сделать нужно подробное техническое задание. И задать вопрос - у Вас есть такое задание? Если нет, то и цену назвать невозможно. Если кому надо пусть смотрит средние цены по рынку.
В любом случае заказчик платит поэтапно и на любом этапе он может увидеть - получается у него работать с этим разработчиком или нет, есть движение, или ему лапшу на уши вешают. В конце концов все уже взрослые люди и могут отличить, где специалист, а где клоуны.
Привести заказчика, а заодно и разработчика, к состоянию взаимопонимания - это конечно большая тема и я ее затронул лишь косвенно. Но это может когда-нибудь потом.
Еще один момент в планировании - итерации. Очень важный момент - что главным критерием этапов работы становится не их содержание, выполнен план или нет, а именно временные рамки - время вышло, дидлайн! все!, срок закончен, начинается разбор полетов - что сделано, что не сделано, почему и что делать дальше. Это очень и очень важно. Это средство для лечения срывов по срокам, да и по деньгам то же.
Границы временных интервалов тоже следует делать не очень большими, но и не очень маленькими. Оптимально квартал, с промежуточными ключевыми точками раз в месяц.
Чем регулярнее и серьезнее делаются итерации, тем меньше риск завалить проект.
И наконец самое последнее, что хотелось сказать - это внедрение. Если кратко, то основная работа здесь - это реинжиниринг мотивации. Это может не очень обычно звучит, реинжиниринг обычно относят к бизнес-процессам. Но на самом деле речь идет именно об управлении мотивацией, о ее изменении у пользователей. Пользователи всегда будут сопротивляться (Обратная сторона - пользователи никогда не будут открыто восторгаться нашей автоматизированной системой :)
Разработчику надо не заводиться в истерике от этого сопротивления, а принять его как реальность (с) - М.С. Горбачев) и разработать план действий по изменению этой мотивации.
И очень хорошо, если тот, кто руководит работой по внедрению, типа акаунт-менеджера проекта, подкован в психологии (особенно психоанализ, групповая динамика, невербальная коммуникация и т.д.)
Очень большая ошибка думать, что внедрение начинается после обследования и настройки программы.
Лучше всего начинать внедрение после (а то и до) подписания договора и получения аванса путем организации общего совещания начальников отдела и зам генерального, который ведет проект, на котором рассказать, как разработчик собирается внедрять систему, представить общий план действий и спросить у присутствующих, что они думают по этому поводу. Это бывает очень полезно по многим причинам, причем даже не только для разработчика, а для самого заказчика. Там, например, очень часто обнаруживается, что точка зрения начальства не совпадает с мнением начальников отделов, или что в разных подразделениях одни и те же операции выполняются по разному и т.д. Не говоря уже о том, что на таком совещании начальники отделов видят разработчиков и потом уже на шарахаются от них, как от незнакомых чужаков. Плюс они видят, что музыку заказывает зам генерального, поэтому и слишком вольничать с разработчиками по ходу им не следует.
И такие совещания, в разных форматах - с начальниками отделов, с конечными пользователями и т.д. - желательно проводить почаще, не реже чем раз в месяц.
Потому что с одной стороны всегда найдется масса вопросов, которые надо по ходу прояснить. Например, очень часто обнаруживаются дырки в учетной политике и в самих бизнес-процессах и от этих дырок не стоит разработчику отмахиваться, типа это не мое дело, наведите порядок, чтобы мне не автоматизировать хаос, а надо засучить рукава и инициировать процесс наведения этого порядка.
Если заказчик видит, что ты вместе с ним борешься с этим самым хаосом, поверьте, многие вопросы после этого будут решаться гораздо иначе.
И еще одно правило, которое иногда воспринимают как некую уловку, но которое на самом деле необходимо просто потому, что в жизни так оно должно и быть. А именно - мало сделать работу, надо еще и показать, что ты ее сделал.
Заказчику не нужны проблемы разработчика, что там чего-то не так, и что рассчитать все заранее невозможно, и что главбух саботирует, и что у 1С эта функция не реализована и т.д.
У него хватает своих проблем и он хочет позитива, он хочет, чтобы хотя бы у кого-то что-то получалось, он хочет, чтобы разработчик сам находил язык с пользователями, чтобы он мог разобраться в хитросплетениях не только бизнес-процессов и учетной политики, но и в тонкостях отношений на предприятии, и чтобы самое главное - было движение, был результат. Причем, чтобы этот результат видел не только генеральный, но чтобы и рядовые пользователи, и начальники отделов, где-то на совещании, или мимоходом в коридоре, подтвердили, что да, действительно, система внедряется, что уже что-то работает, что уже остатки на складе реальны процентов на 75, что отдел продаж уже перешел с Excel'я на 1С, а бухгалтерия отказалась от старой версии 7.5, что мастер на заводе уже пользуется накладной из общей автоматизированной системы на внутреннее перемещение готовой продукции из цеха на склад готовой продукции, и что экономист уже берет из этой новой системы данные для отчетов по статистике и т.д.
И если все это делается, но босс об этом не знает, или знает мало, то это вина разработчика. Как говорится в старинной английской/американской/русской пословице - если ты сам себя не похвалишь, то кто же это будет делать за тебя? :)
В общем, вот такие соображения захотелось высказать по итогам этой дискуссии.
С уважением Максим С
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4375 от 2007-02-23 участников 1887 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Что-то вдруг тема так резко оборвалась, хотелось бы еще кого-нибудь послушать.
Например, очень интересует именно контроллинг в этой области - как оценить эффективность внедрения ERP?
С уважением Максим С
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4376 от 2007-02-26 участников 1886 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Что-то вдруг тема так резко оборвалась, хотелось бы еще кого-нибудь > послушать. >
> Например, очень интересует именно контроллинг в этой области - как > оценить эффективность внедрения ERP?
У информации есть 3 критерия качества: 1. оперативность 2. достоверность 3. полнота
Если в результате внедрения ERP, качество обработки информации в Компании улучшено хотя бы по одному из этих критериев, то внедрение прошло не зря.
Критерии оценки эффективности у всех разные - это человеко-места, чаловеко-часы, количество операций, количество бумаги, трафик серверов и т.д. Все можно перевести в деньги и сравнить с тем, что получилось в результате.
-- Best regards Mikhail
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4377 от 2007-02-26 участников 1886 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Уважаемый Максим Сидорович! Михаил пишет:
> У информации есть 3 критерия качества: > 1. оперативность > 2. достоверность > 3. полнота … > результате.
Помимо того, что у информации есть несколько больше критериев качества, хочу возразить по поводу самой оценки эффективности внедрения ERP. Поскольку это система Планирования Ресурсов Предприятия (по определению), то ее эффективность следует оценивать исходя из результатов этого самого планирования - оптимизации всех видов ресурсов, т.е. прирост капитала именно за счет этого. При этом каждый из ресурсов (эффективность его использования) можно оценивать отдельно, исходя из его собственных уникальных факторов создания стоимости или КПЭ. Образно говоря, эффективность управления автомобилем определяется не дизайном панели управления, а тем, как этот дизайн повлияет на скорость, безопасность или объем грузоперевозок.
-- С уважением, Владимир
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4378 от 2007-02-28 участников 1882 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
И, как того просил Максим Сидорович, продолжаю тему.
> При этом каждый из ресурсов > (эффективность его использования) > можно оценивать отдельно, исходя > из его собственных уникальных > факторов создания стоимости или КПЭ.
Скажем, в вопросе материального обеспечения производства (логистика в снабжении)основной фактор создания стоимости - снижение издержек. Разумеется, всех, связанных с этим процессом - издержек на закуп, на траспортировку, на хранение и т.п. Фактически, выполняя закуп, мы инвестируем средства в материальное обеспечение производства. Следовательно, нужно учитывать и затраты на капитал. Оптимизируя все параметры закупа (в т.ч. складские запасы и сроки их хранения) мы получаем прирост стоимости и за счет снижения затрат на капитал. Сравнив эти факторы без ERP и с его внедрением можно оценить и эффект. И вообще, ERP это целый комплекс решений. Его необязательно внедрять сразу и весь. И оценивать эффект удобнее отдельно по каждому процессу, входящему в систему. Более того, в зависимости от характера и сложности бизнеса может и не потребоваться внедрение ВСЕХ элементов ERP. И нет ничего страшного, если элементы реализованы на различных платформах. По крайней мере, при всем уважении к 1С я бы не стал использовать встроенный модуль CRM (управление отношениями с клиентами). Да и производственное планирование там весьма ограниченное, хотя при определенной доработке может быть очень эффективным (по собственному опыту).
P.S. Надеюсь, у наших белорусских друзей все отлично, Максим Сидорович? Рад снова видеть вас в ДЛ -- С уважением, Владимир
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4379 от 2007-03-02 участников 1884 Написать: economics.school.controlling-list@subscribe.ru ======================================================================== Володя, а как ты это реально себе представляешь? У Вас на предприятии это делалось? -- С уважением Максим С
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4380 от 2007-03-02 участников 1884 Написать: economics.school.controlling-list@subscribe.ru ======================================================================== Я тоже рад вынырнуть из текучки :)
Предыдущее письмо уехало, не видя этого, поэтому кое-что уже здесь уже ответилось.
Но все-таки, Володя, Вы у себя это делали? Я это спрашиваю потому, что сколько ни искал, нигде нет удовлетворительного ответа.
Хочется все-таки убедиться, что хоть может у Вас это реально делалось :)
И еще такой вопрос, опять же как человеку опытному, можешь ли ты назвать какой-то норматив затрат на ИТ (в совокупности, а если по статьям, так и вообще супер!), например, от оборота, от чего-то еще и т.д. Вон на НИОКР там читаешь у буржуев, типа 2-3 или 5-10%, на рекламу типа 5-7%, а сколько все-таки желательно заряжать на ИТ?
-- С уважением Максим С
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4381 от 2007-03-03 участников 1879 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> И еще такой вопрос, опять же как человеку опытному, можешь ли ты > назвать какой-то норматив затрат на ИТ (в совокупности, а если по > статьям, так и вообще супер!), например, от оборота, от чего-то еще > и т.д. Вон на НИОКР там читаешь у буржуев, типа 2-3 или 5-10%, на > рекламу типа 5-7%, а сколько все-таки желательно заряжать на ИТ?
Заряжать на ИТ нужно столько, сколько необходимо в данном конкретном плановом периоде в конкретной фирме для реализации этой фирмой всех целей, которые она должна достичь по завершению данного периода. А это требует, для начала, качественного изменения самого процесса планирования. Если процесс планирования организован правильно, то он потребует инструмента - в виде системы управления. А система управления - это не одно и тоже, что и ERP. ERP - это всего лишь одна из подсистем в системе управления.
На этапе построения системы управления бюджет ИТ может быть одним, а на этапе текущей эксплуатации системы, совершенно другим, а конкретные пропорции зависят от конкретной ситуации в конкретной фирме, и начинать составление бюджета с бенчмаркинга принципиально не рекомендую - обычно это ни к чему хорошему не ведет.
Андрей Наумов
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4382 от 2007-03-16 участников 1877 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
- >> кой вопрос, опять же как человеку опытному, можешь ли ты >> >
> Заряжать на ИТ нужно столько, сколько необходимо в данном конкретном плановом … > > Андрей Наумов >
*** На самом деле вопрос ставится иначе. Во многих случаях практически невозможно рассчитать стоимость автоматизации. И какие бы при этом не рисовались схемы или не выполнялись расчеты, стоимость меняется и остаются в проигрыше и заказчик, который тратит кучу денег непонятно на что, и исполнители, которые работают в убыток.
Поэтому в ряде случаев мы склоняемся к схеме бюджетирования, когда выделяется определенная сумма на месяц и под нее выполняются определенные объемы работ.
И бенчмаркинг здесь очень даже помогает. Например, известно, что внедрении 1С 8.0 Управление производственным предприятием занимает порядка 1,5 - 2 года.
Отсюда, примерный срок уже известен, стандартный набор задач тоже.
Тогда распределяем последовательность и прикидываем ресурсы, кто будет участвовать, какие зарплаты, накладные и т.д. Получается помесячный бюджет, где более конкретно, чем в общей сумме, исполнитель может рассчитать свою прибыль, а заказчик свои возможности по финансам.
И вот здесь очень хотелось бы привязаться к какой-то цифре, которая бы с одной стороны была посильна заказчику и, с другой стороны, была интересна исполнителю.
В итоге получается, что предприятие так или иначе должно выделять определенные средства на автоматизацию. Причем, не играет особой роли внедрение это или сопровождение. Чем больше внедрено, тем больше надо сопровождать и бюджеты почти выравниваются.
А если это постоянные затраты, то было бы неплохо оценить их как долю в общей сумме затрат. Я уже упоминал рекламные затраты, ведь они уже есть постоянная статья расходов и есть отраслевые ориентиры, сколько кто тратит. И там ведь посмотрите, никто особенно не делит их по конкретным мероприятиям, есть бюджет, а под него уже планируются возможности. То же примерно происходит сейчас и с затратами на обучение сотрудников. Самое главное в таком подходе, что это уже не разовые а именно постоянные затраты, навсегда, на всю оставшуюся жизнь. Т.е. руководство предприятия понимает, что без этого уже не обойтись, и на это нужно выделять средства. Отсюда следующий вопрос - сколько нужно этих средств и как определить этот объем. Вариант - по предыдущему году (периоду), по факту планируемых мероприятий, по среднеотраслевому нормативу/ориентиру и т.д.
Поэтому, мне ИМХО кажется, что расходы на ИТ могут быть и должны также нарисоваться как некая доля в общей массе затрат. Их можно рассчитать чисто эмпирически, либо посмотреть у других, либо еще каким-то способом.
С уважением Максим С
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4383 от 2007-03-16 участников 1877 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Поэтому, мне ИМХО кажется, что расходы на ИТ могут быть и должны также > нарисоваться как некая доля в общей массе затрат. Их можно рассчитать > чисто эмпирически, либо посмотреть у других, либо еще каким-то способом.
При правильной организации работ в области ИТ (да и не только) на плановый период должны быть поставлены конкретные цели и определена последовательность работ, осуществление которых приведет к достижению этих целей. А зная все работы, которые необходимо осуществить в плановом периоде, можно просчитать и необходимый для этого бюджет.
Вы же предлагаете выделить волевым решением какую-то сумму денег для решения задач в области ИТ. При таком подходе постоянно будут возникать вопросы - на что нужно, а на что не нужно тратить выделенные в бюджете деньги, что в конечном итоге не гарантирует достижения какого-то конкретного результата по завершению планового периода, а лишь гарантирует, что выделенные в бюджете средства будут освоены.
Вот такие существуют два противоположных подхода к бюджетированию:
1.Бюджетирование, направленное на обеспечение получения конкретного результата;
2.Бюджетирование, предназначенное для освоения выделенных в бюджете средств без гарантирования достижения конкретного результата.
Второй подход проще, но первый несоизмеримо эффективней.
С наилучшими пожеланиями,
Андрей Наумов
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4384 от 2007-03-18 участников 1875 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
Доброго времени суток!
Андрей, поддерживаю Вас. Далее по тексту.
* Андрей Наумов [Fri, 16 Mar 2007 11:52:58]: >> Поэтому, мне ИМХО кажется, что расходы на ИТ могут быть и должны … > Второй подход проще, но первый несоизмеримо эффективней.
Отличный пример принципа успешности бизнеса от Джима Коллинза: "Важно не что делать, а с кем делать".
1. План действий по достижению поставленных целей (надеюсь цели по прибыли или стоимости, а не по совершению действий) разрабатывает менеджер. Тот, кто намерен этот план осуществлять. 2.План для менеджера делает финансист (специалист, в чью профессиональную компетенцию не входят специализированные знания по планированию и контролю). При чем не план действий, а план движения денег от действий менеджера. И далее, сам менеджер, должен подстраиваться под тот план, который ему написал финансист (заметьте, написал не специалист в области планирования). Это и есть бюджетирование - планирование в представлении финансистов :-)
Кстати, сейчас читаю Джек Уэлч и Сюзи Уэлч "Ответы на 74 ключевых вопроса о современном бизнесе". Вопрос No34 "Бюджетная бессмыслица, и как ее избежать". Резюме от авторов: - эффективное планирование - это совершенно иное, чем современное бюджетирование :-).
Кстати, планирование ИТ - это одна из программ (функциональных областей действий в подразделениях предприятия), которые составляют совокупный план, на основании которого и оформляется бюджет -- С уважением, Дмитрий Ковал¨в
-*-------------------------------------------------------------------------- КОНТРОЛЛИНГ и Управленческий Учет: вопросы и ответы N 4385 от 2007-03-18 участников 1875 Написать: economics.school.controlling-list@subscribe.ru ========================================================================
> Вот такие существуют два противоположных подхода к бюджетированию: > 1.Бюджетирование, направленное на обеспечение получения конкретного > результата; > 2.Бюджетирование, предназначенное для освоения выделенных в бюджете > средств без гарантирования достижения конкретного результата. > Второй подход проще, но первый несоизмеримо эффективней.
Вы не правы, причем кардинально.
Именно при том подходе, о котором говорилось выше, как раз таки и есть цели и способы их достижения. Обратите внимание, там ранее шла речь о периоде, по окончании которого эти цели достигаются - 1,5 - 2 года.
А вот внутри этого периода планируются работы помесячно, где на каждый месяц ставятся свои цели, вытекающие из общих -- С уважением Максим С
-*--------------------------------------------------------------------------
|
